A typical automobile includes a myriad of sensors mounted around the engine and other vehicle modules for monitoring the condition and selected performance characteristics of the vehicle such as air intake, temperature, and the position and rate of change of the accelerator, etc. Typically, an engine computer, also referred to as a Powertrain Control Module (PCM), is provided in the vehicle for monitoring the sensors and providing control of various engine functions as a function of sensor data. The PCM typically makes adjustments to minimize exhaust pollution, minimize fuel consumption, and maximize engine power.
Partly in response to governmental vehicle pollution mandates, an OnBoard Diagnostics (OBD) system is typically provided in the vehicle in order to require the PCM to actively monitor and test the engine parameters and in particular, the emissions-related elements. The OnBoard Diagnostics system requires that sensors and actuators controlling pollution monitoring are checked regularly and codes generated if a fault is detected. Other diagnostic systems such as OBD-II go a step further and require the PCM to actively monitor and test the emissions-related elements. An OnBoard Diagnostics port is typically provided which enables access to the engine computer and the diagnostic codes provided by the OBD system. The diagnostic port is typically accessible from either under the hood or from the interior passenger compartment of the vehicle to facilitate monitoring and control of the vehicle's engine characteristics. Conventionally, the monitoring and troubleshooting of identified faults required the use of bulky, complex equipment that was available only at automobile repair establishments. The operation of the conventional test equipment also required the knowledge and skill of a trained mechanic. Many vehicle operators desire the capability to accurately control, monitor, and evaluate vehicle performance themselves without the need for bulky, complex equipment or a mechanic. The diagnosing of certain engine problems and the monitoring of certain engine performance characteristics conventionally requires the use of a dynamometer. A dynamometer or “dyno” is a device used to measure power and torque produced by the engine. There are typically two types of dynos, an engine dyno that gets bolted directly to an engine, and a chassis dyno that can measure horsepower and torque without requiring that the engine be removed from the frame of the vehicle. Known devices exist for separately programming the programmable engine functions.
A vehicle operator may also be interested in measuring the speed performance of the vehicle, e.g., quarter mile time, time to speed, and top speed. Conventionally, a drag strip or other location is used and requires another person and/or one or more external devices to monitor the vehicle position and to provide a timer for determining the quarter mile time and speed.
A vehicle operator typically also desires to have a display of vehicle operating conditions. The cost of accessory gauges to display these operating conditions, however, are often cost prohibitive and difficult to install. Vehicle operators are also typically interested in having ready access to diagnostic data and their descriptions for troubleshooting purposes.
There is therefore a need for a multipurpose device and method that provides a performance tuning function, a dynamometer function, and a drag strip function via a portable device that a user can readily install by plugging it into the diagnostic connector port of the vehicle. There is a need for a device and method that also enables a user to monitor selected characteristics of the engine and other vehicle systems. There is a need for a device and method that also enables a user to selectively display diagnostic data based on data read from the onboard diagnostics system port. There is also a need for displaying vehicle operating conditions to a user without the need for costly accessory gauges. A need also exists for providing the above features in a device that has a user friendly interface for enabling easy operation of the monitor, evaluation, and control functions.
There are known vehicle programmable automotive devices that interface with the vehicle's diagnostic port to obtain velocity information, e.g. OBD-II based devices, also referred to as PID-based devices. There are also known vehicle programmable automotive devices that are accelerometer-based and do not interface with the vehicle diagnostic port. The advantage of known accelerometer-based devices is that these devices provide a precise starting time and point and are not affected by wheel-spin errors caused in distance calculations. A drawback of such devices is that the accelerometer requires very careful installation. A key drawback of these accelerometer-based devices is the requirement of precise alignment with the vehicle's x, y, and z axes of movement, and especially the longitudinal axis, e.g., the straight line direction down a drag strip track. The requirements for precise alignment with respect to these three axes are virtually impossible for known accelerometer-based devices to meet. As a result, errors in the outputs generated by such devices are inherent and unavoidable. Moreover, any misalignments of the accelerometer causes errors in the vector pointing down the track which results in a continuously increasing error in the velocity values, the first integral of the accelerations. This error for accelerometer-based devices is further compounded in the distance calculations, the second integral of the accelerations.
Accelerometer-based devices are also subject to errors due to “bouncing” and “tilting” during acceleration of the vehicle. For example, the lifting of the vehicle's front end and the dropping down of the rear end exhibited during acceleration both affect the vector for straight line acceleration, thereby causing both random and systematic errors. The removal and reinstallation of an accelerometer based device in a slightly different orientation, or any “bumping” of the device will cause different results from otherwise identical vehicle test runs. For all of the above reasons, known accelerometer-based devices have the drawback of being subject to error.
There is therefore a need for a method, and device that overcomes the drawbacks of known accelerometer-based devices. Known parameter identification based (PID-based) devices rely on velocity data from the vehicle's diagnostic port for their performance calculations and measurements. These known PID-based devices are also referred to herein as PID-velocity devices. The velocities read from the diagnostic port for such devices are not accelerometer based and thus are not affected by vehicle bouncing or tilting. As a result, PID-based devices can be mounted in any orientation.
Two of the drawbacks of known PID-based devices are that the initial starting point and starting time are unknown. The velocity data available at the diagnostic port is obtained using a pulse generator driven off the drive-train and in proportion to road speed. The resolution of the pulse generator varies from vehicle to vehicle, however. Consequently, it is unknown whether a pulse is produced every few inches or every few feet.
There is therefore a need for accurately and reliably accounting for this unknown distance between pulses that causes an error at the start of a test run for known PID-based devices. The PCM software of the engine computer calculates the velocity data accessible from the diagnostic port based on “time between pulses” measured by a sensor on the output shaft of the transmission. The output shaft rotates at the drive shaft rotational speed such that one or more pulses are generated every time the drive shaft turns one complete revolution. The typical distance on the shaft between pulses is less than 0.75 inches. The engine computer cannot deliver the first velocity value based on time between pulses until after the first two pulses have occurred.
In order to accurately measure the time and distance down the track from the very start, the distance and time measurements must begin simultaneously at the precise moment the vehicle moves. The time interval and the short distance traveled from “first movement” until the first pulse is not known based on any of the data available from any known diagnostic port. In other words, the vehicle might be at rest with the sensor on the output shaft of the transmission on the verge of “triggering”, or it might be at rest with the sensor having just “triggered”, or it might be anywhere in between. As a result, there is an unknown error such that any previous attempts at using PCM velocity values provided at the diagnostic port to generate distance traveled and acceleration tests have always contained an error that varies from test to test randomly, and, therefore, gives false, unreliable fluctuating results.
There is therefore a need for a detector for detecting the start time of first movement of the vehicle independent of the onboard diagnostic system and its diagnostic port.
In addition to not knowing the precise starting point on the track for a test, the initial time “zero” of the test, i.e., the moment in time of first movement by the vehicle, is also an unknown for conventional PID-based devices. The time can only begin in known PID-velocity based devices when the first non-zero velocity appears as a PID at the diagnostic port. For known PID-velocity based devices, therefore, nothing can be known about the time that has elapsed nor the distance that has been traveled, prior to the first non-zero PID velocity report.
There is therefore a need for a detector for detecting the start time of first movement of the vehicle independent of the onboard diagnostic system and its diagnostics port. A “first movement” trigger is needed such that the precise time taken to reach the first velocity values delivered by the PCM to the diagnostic port can be accurately determined.
Wheel spin presents another challenge because the velocity values from the diagnostic port are distorted during the time the vehicle's wheels are spinning, such that distance calculations would otherwise be inaccurate. Wheel spin can occur at varying times and distances down the track. The velocity data at the diagnostic port falsely reports excess speed for the entire time duration of a “wheel spin” condition. As a result, the integral of the velocity curves is exaggerated and all distances and time-to-distance calculations are incorrect and in proportion to the falsely-reported excess speed during the wheel spin. Known PID-based devices do not accurately account for this wheel spin error.
There is therefore also a need for a method that detects and accurately and reliably accounts for wheel spin.